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Varfahren und Vorrichtunp f»r einen f ahrzeugbezorcnen Telematikdienst 
Stand der Technik 

Die Erfindung betrifft ein Verfahren und Vorrichtung fiir einen fahrzeugbezogenen 
Telematikdienst wie das Einwirken auf wenigstens eine Funktionalitat in einem Fahrzeug 
Uber eine Luftscnnittstelle, z.B. ein Mobilfunknetz, insbesondere in Verbindung mit der 
Femdiagnose von Kraftfahrzeugen. 

Die zunehmende Vernetzung von Steuergeraten in heutigen Kraftfahrzeugen bietet immer 
bessere EinwirkungsmogUchkeiten auf Funktionalitaten im Kraftfahrzeug, z.B. bessere 
DiagnosemSglichkeiten im Fehlerfall oder Moglichkeiten zur Fernbedienung von 
Funktionen und/oder Komponenten des Fahrzeugs. In diesem Zusammenhang bestehen 
Konzepte, mit Hilfe eines mobilfunkgestiitzten Einwirkens zuverlassig und sicher auf die 
Funktionalitat im Fahrzeug Uber beliebige Entfernungen hinweg zuzugreifen, 
beispielsweise liber eine Femdiagnose zuverMssige und qualitativ hochwertige 
Fehleranalysen durch ein Service-Center bzw. einen Femdiagnose-Server, der eine 
entsprechende Diagnose-Datenbank umfasst, durchzufuhren. GemaB diesen Ansatzen 
werden im Fahrzeug integrierte Kommunikationssysteme wie beispielsweise 
Mobiltelefone und/oder GSM-gestutzte Telematikendgerate genutzt, urn eine 
Dateniibertragung zwischen den an ein Fahrzeugnetzwerk angeschlossenen Steuergeraten 
und/oder Komponenten und dem Server des Service-Centers durchzufuhren. Einen 
Vorschlag fiir ein derartiges System beschreibt die DE 100 26 754 Al. Eine konkrete 
Realisierung hinsichtlich der Ubertragungsinhalte zwischen Server undEndgerat sowie 
hinsichtlich der Ausgestaltung von Endgerat bzw. Server werden nicht angegeben. 



VorteUe der Erfindung 
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Durch die Aufteilung der Funktionen, z.B. Diagnosefunktionen, zwischen Endgerat und 
Server (Partitionieren von Teilfunktionen) wird eine erhebliche Ressourcenerspamis im 
Fahrzeugendgerat erreicht Besonders vorteilhaft ist, dass zeitunkritische, 
fahrzeugspezifische Funktionen, mit denen das Einwirken auf die ausgewahlte 
Funktionalitat gesteuert wird, nicht im Fahrzeugendgerat, sondern im Server vorgehalten 
werden und von diesem liber die Luftschnittstelle ubertragen werden. Dadurch wird 
vermieden, dass ein zusatzliches, speziell auf die Anwendung insbesondere hinsichtlich 
vom Fahrzeugnetzwerk vorgegebenen zeitlichen Randbedingungen zugeschnittenes 
AppUkations-Protokoll fiir die Luftschnittstelle notwendig ist, so dass auf iibliche 
Standard-Protokolle fiir die Luftschnittstelle zuriickgegriff en werden kann. Erganzend 
erlaubt die tFbermittlung von fahrzeugspezifischen Informationen uber die 
Luftschnittstelle eine einheitliche, parametrisierbare Funktionalitat im Endgerat sowie 
eine fahrzeugunabhSngige Implementierving im Endgerat. Eine besonders hohe 
Flexibility des Systems wird erreicht, die sich auch sich andernde Ausstattungen der 
Fahrzeuge anpassen kann. 

Bei der Ferndiagnose sind Anderungen oder Verbesserungen im Bezug auf die Diagnose 
selbst, sofem diese nicht Onboard in den Steuereinheiten des Fahrzeugs ablaufen, im 
Server m5glich. Dies betrifft vor alien den Ablauf und Umfang (iibertragene Daten) des 
Femdiagnosevorgangs. 

Besondere Vorteile werden in Verbindung mit der Ferndiagnose erreicht, wenn die 
Kommandos des fahrzeugspezifischen Diagnose-Protokolls liber die Luftschnittstelle 
vom Server zum Endgerat ubertragen werden. 

Durch die Ressourcenerspamis im Fahrzeugendgerat, insbesondere durch die 
Auslagerung zeitunkritischer Vorgange in den Server des Service-Centers wird eine 
einfache und schnelle Umsetzung auf das Fahrzeugnetzwerk im Endgerat moglich. 

Somit ergibt sich insgesamt eine effiziente und vor allem mit geringem Aufwand 
implementierbare Vorgehensweise zum Einwirken auf eine Fahrzeugfunktionalitat, vor 
allem zur Ferndiagnose, Femwartung, Femsteuerung, Software-Download, etc. bei 
Kraftfahrzeugen. 
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Weitere Vorteile ergeben sich aus der nachfolgenden Beschreibung von 
Ausfuhrungsbeispielen bzw. aus den abhangigen Patentanspriichen. 

Zeichnung 

Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten 
Ausfuhrungsformen anhand der Ferndiagnose eines Kraftfahrzeugs naher erlauterL 
Figur 1 zeigt ein Prinzipbild eines Ferndiagnosesystems. 

In Figur 2 ist als tTbersichtsdarstellung die Aufteilung der Diagnosefunktionalitat 
zwischen fahrzeugseitigem und serverseitigem Teil des Systems dargestellt. Insbesondere 
ergeben sich daraus auch Ausgestaltungen des Fahrzeugendgerats bzw. des Servers des 
Service-Centers . 

Figur 3 zeigt ein Ablaufdiagramm, welches den grundsatzlichen Ablauf der Ferndiagnose 
insbesondere im Hinblick auf die ttbertragung zwischen Server und Endgerat sowie im 
Hinblick auf die Funktionen des Endgerats bzw. des Servers in einem bevorzugten 
Ausfuhrungsbeispiel darstellt. 

Figur 4 zeigt die Kommunikation zwischen Server und Endgerat sowie zwischen 
Endgerat und zu diagnostizierendem Steuergerat sowie die in den jeweiligen Einheiten 
ablaufenden Vorgange im Detail anhand eines bevorzugten Ausflihrungsbeispiels. 

Beschreibung von Ausfuhrungsbeispielen 

Figur 1 zeigt ein Ubersichtsbild eines Systems fur einen fahrzeugbezogenen 
Telematikdienst, wobei Inf ormationen zwischen einem Fahrzeug (dort Endgerat) und 
einem Server iiber ein Mobilfunknetz bzw. iiber ein Datennetz, wie beispielsweise das 
Internet, ausgetauscht werden. Eine derartige Konfiguration wird in Verbindung mit 
Funktionen zur Fernwirkung, Ferndiagnose, Fernwartung, Software Download, etc. 
eingesetzt. Unter Fernwirkung bzw. Fernabfrage wird dabei im wesentlichen die 
Fernsteuerung von Fahrzeugfunktionen, insbesondere Komfortfunktionen wie das 
Einschalten der Standheizung, etc., sowie das Abfragen von Fahrzeugstati und/oder 
Betriebsparametern verstanden. Dabei inifiiert der Nutzer eine Kommunikation mit dem 
Fahrzeug iiber einen zentralen Server oder er kommuniziert direkt mit dem Fahrzeug. 
Ferndiagnose umfasst das Fernauslesen von Diagnosedatenaus dem Fahrzeug, deren 
Analyse und ggf. das Erzeugen einer Empfehlung fiir das weitergehende Handeln. 
Analyse der Daten und Generierung derEmpfehlung-erfolgt dabei durch einen zentralen 
Server, der mit dem Fahrzeug iiber ein Mobilfunknetz, iiber ein drahtgebundenes Netz 
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und/oder iiber ein Datennetz wie beispielsweise das Internet mit dem Kraftfahrzeug in 
Verbindung steht. Ferner ist in diesem Zusammenhang als Funktion der sogenannte 
Software-Download bzw. das Remote-Hashing zu nennen, mit deren Hilfe ein neuer 
Programmcode oder Parameter auf per Software konfigurierbare Systeme im Fahrzeug, 
beispielsweise Steuergerate, auf gebracht werden, um die Funktionalitaten oder die 
Leistungsfahigkeit zu erhohen. Auch hier erfolgt die Konununikation iiber ein 
Mobilfunknetz, ein drahtgebundenes Netz und/oder beispielsweise das Internet 
ausgehend von einenLzentralen Rechner (Server) bzw. Service-Center. Fernwartung stellt 
im wesentlichen die Uberwachung des Fahrzeugzustandes und den Zugriff auf die 
Wartungsdaten im Fahrzeug von einer zentralen Stelle aus dar, um zu iiberpriifen, ob, 
wann und welche MaBnahmen zur Wahrung des Sollzustandes durchgefiihrt werden. Ein. 
Beispiel hierfiir ist das dynamisctie Anpassen von Wartungsintervallen. Allgemein 
werden diese Funktionalitaten hier unter dem Begriff des fahrzeugbezogenen 
Telematikdienstes subsumiert. 

Figur 1 zeigt einen fahrzeugseitigen Teil 1 sowie einen serverseitigen Teil 2. Beide Teile 
sind iiber eine Kommunikationsschnittstelle 3, insbesondere eine Luftschnittstelle, 
beispielsweise uber ein Mobilfunknetz miteinander verbunden. Der fahrzeugseitige Teil 
besteht aus einem Endgerat 4, beispielsweise einem Telematikendgerat, welches iiber 
eine weitere Schnittstelle 5 mit der Fahrzeugelektronik 6 verbunden ist. Der serverseitige 
Teil 2 besteht aus einem Server 7, welcher beispielsweise von einem Service-Center, dem 
Fahrzeughersteller oder einem Zulieferer betrieben wird, und der uber eine Schnittstelle 8 
mit einem Datenspeicher 9 in Verbindung steht, in dem beispielsweise im Rahmen einer 
Datenbank f ahrzeugbezogene Daten und/oder Kommandos und/oder Programme abgelegt 
sind. Wie nachfolgend im Detail beschrieben, werden bei dem dargestellten Client- 
Server-System Teilfunktionen partitioniert, d.h. dem Server und den Client bestimmte 
Funktionalitaten eines Telematikdienstes zugeordnet. Dabei wird von einer vollstSndigen 
Vemetzung der zu diagnostizierenden bzw. zu steuerndeh Steuergerate im Fahrzeug mit 
demEndgerats z.B. durch einen CAN-Bus sowie von der Verfligbarkeit der Schnittstelle 
3, insbesondere einer Mobilfunkschnittstelle im Kraftfahrzeug, ausgegangen. Die 
bekannten, unterschiedlichen Verfahren fur die Erfassung von Diagnosedaten, 
beispielsweise uber eine CAN-Bus-Schnittstelle, lassen sich in nichtzeitkritische und 
zeitkritische Anwendungen aufteilen. Zu den nichtzeitkritischen Anwendungen gehort 
beispielsweise die Ablaufsteuerung des Diagnose-Testers, mit Zugriff auf eine 
Diatenbank, sowie das Diagnose-Protokoll selbst, beispielsweise das Protokoll KWP2000 
bzw. Varianten davon. Zeitkritische Anwendungen sind das Transport-Protokoll des 
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Fahrzeugnetzes (z.B. CAN-Transport-Protokoll) oder Varianten davon, dessen 
Kommunikationsschicht (z.B..CAN-Kommunikationsschicht) sowie der Bus (z.B. CAN- 
Bus) selbsL Wesentlich ist, dass bei der Implementierung der Telematikfunktion im 
Kraftfahrzeug die zeitkritischen Vorgange gegeniiber dem unsichereren Mobilfunkkanal 
entkoppelt werden. Daher werden alle oder eih Teil der relevanten Funktionen aus dem 
Fahrzeug ausgelagert, bei denen keine engen zeitlichen Anforderungen bestehen, 
insbesondere Anforderungen bezugliche einer minimalen oder maximalen Zeitdauer 
zwischen Kommando und Antwort bei einer Datenubertragung. Im Extremfall bleibt 
daher lediglich der zeitkritische Datentransport auf demFahrzeug-Bus (z.B. CAN-Bus 
oder Ahnliches), welcher durch Funktionen des Transport-Protokolls wie beispielsweise 
die Fragmentierung und Defragmentierung komplexer Nachrichten, realisiert ist, auf der 
Client- bzw. Fahrzeugseite zuriick. Der Funktionsumfang des in der Regel komplexeren 
und fabxzeugspezifischenDienste-Protokolls (z.B. Diagnoseprotokoll) wird dabei auf 
einen entsprechenden Server (z.B. Diagnoseserver) ausgelagert. Im Anwendungsfall der 
Femdiagnose werden neben der ttbertragung fahrzeugspezifischer Diagnose-Kommandos 
auf der Basis des jeweils verwendeten Diagnose-Protokolls ferner zusatzliche 
Informationen zwischen der Server-Applikation (Ablaufsteuerung fur den 
Gesamtvorgang) und der Client-Applikation (Ablaufsteuerung zur Datenerfassung) 
iibertragen. Diese Ablaufsteuerungen dienen der Aktivierung des Diagnosevorgangs, der 
Konfiguration der Client-Applikation und der spateren Obermittlung von Ergebnissen der 
serverseitigen Datenanalyse. In dem skizzierten Beispiel, bei dem alle zeitunkritischen 
Vorgange aus dem fahrzeugseitigen Teil in den serverseitigen Teil des Systems 
ausgelagert wurden, ergibt sich die in Figur 2 dargestellte Systemarchitektur. In anderen 
Ausfiihrungen wird nur ein Teil der nichtzeitkritischen Vorgange ausgelagert, wahrend 
ein Teil im fahrzeugseitigen Endgerat verbleibt. So ist beispielsweise vorstellbar, dass 
fahrzeugspezifische Daten und/oder spezielle fahrzeugspezifische Diagnose-Kommandos, 
die aus Sicherheitsgriinden nicht ausgelagert werden, im fahrzeugseitigen Teil des 
Systems verbleiben. 

In Verbindung mit anderen Telematikdiensten wie der Femsteuerung von Komponenten, 
den Softwaredownload, etc. wird auf die geschilderte Art und Weise zeitunkritische 
Anwendungen ausgelagert, wahrend zeitkritische Anwendungen im Fahrzeugendgerat 
verbleiben. 



In Figur 2 ist das Fahrzeugendgerat (Client) 4 sowie der Server 7 dargestellt, welche iiber 
eine Luftschnittstelle 3 miteinander verbunden sind. Im bevorzugten Ausfuhrungsbeispiel 
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handelt es sich bei der Luftschnittstelle 3 urn ein herkommliches, beispielsweise auf dem 
GSM-Standard basierendes Mobilfunknetz. In anderen Anwendungen handelt es sich urn 
Mobilfunknetze, die mit anderen Standards arbeiten. Der Server umfasst die folgenden 
Module: ein Mobilfunk-Konmunikations-Protokoll-Modul 7a, ein 
MobUfimkkommunikation-Modul 7b, ein Ablaufsteuerungs-Modul 7c sowie ein 
fahrzeugspezifisches Diagnose-Protokoll-Modul 7d. Das Fahrzeugendgerat umfasst 
ebenfalls ein Kommunikations-ProtokoU-Modul 4a, ein Modul 4b zur Kommunikation 
iiber die Mobilfiinkschnittstelle, ein Modul 4c zur CAN-Kommunikation sowie ein 
Transport-Protokoll-Modul 4d. Ferner ist eine Ablaufsteuerung 4e im Fahrzeugendgerat 
vorgesehen. Die Module stellen dabei vorzugsweise Softwareprogramme dar. 

Diese Funktionseinheiten haben die folgenden Aufgaben: 

Die Mobilfunkkommunikations-Module 4b, 7b, die sowohl im Endgerat als auch im 
Server vorgesehenen sind, diesen zur stabilen Datemibertragung, zum Verbindungsaufbau 
bzw. -abbau, der Datensicherheit, gegebenenfalls der Verschliisselung, Packetierung, 
etc. Diese Aufgaben werden von ublichen Koiimiunikationsfunktionseinheiten realisiert 
und sind z.B. imRahmen der GSM-Standards verfiigbar. 

Das im Fahrzeugendgerat vorgesehene CAN-Kommunikation-Modul 4c stellt eine 
hardwareunabhangige Softwareschnittstelle zur Ubertragung von Daten iiber einen CAN- 
Bus zu angeschlossenen Steuergeraten dar. Dazu gehoren die Initialisierung und 
Steuerung des CAN-Controllers, die Ubertragung und den Empfang von CAN- 
Bausteinen sowie tTberlauf-Fehlerbehandlungen und Weckfunktionen. Ferner umfasst das 
Modul die Funktionen der OSI-Layer 1 und 2 (Physical Layer, Data Link Layer). Das 
Softwaremodule arbeitet dabei im Rahmen der giiltigen CAN-Spezifikation. In anderen 
Ausfuhrungen wird anstelle des CAN-Bus ein anderes Bussysteme eingesetzt 
(standardisiert oder kundenspezifisch), wobei das Softwaremodul dann auf der Basis 
einer entsprechenden Spezifikation realisiert ist. 

Die Ablaufsteuerung 7c im Server zerlegt die Diagnose-Grundfunktionen in einzelne 
Teilprozesse bzw. Diagnose-Services, tibernimmt die Mtialisierung des Prozesses, 
steuert und beendet den Diagnosevorgang, verarbeitet die erforderlichen Parameter- und 
gegebenenfalls Protokoll-Mechanismen fur den Diagnosevorgang und steuert den. 
Gesamtvorgang zeitlich. Ferner werden hier die ermittelten Diagnosedaten ausgewertet, 
gegebenenfalls eine Generierung einer Empfehlung durchgefuhrt. Ferner ubemimmt die 
Ablaufsteuerung den Zugriff auf die Diagnose-Datenbank des Servers. Die 
Ablaufsteuerung stellt ein Software-Modul dar, welches fur die spezielle Anwendung 
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konzipiert ist. Ein Beispiel wird nachfolgend anhand der Ferndiagnose in den Figuren 3 
und 4 skizziert. 

In entsprechender Weise ist ein Ablauf steuerungs-Modul 4e im Fahrzeugendgerat 
vorgesehen. Auch dieses Software-Modul ist fur die spezielle Anwendung konzipiert. Ein 
Beispiel wird nachfolgend anhand der Ferndiagnose in den Figuren 3 und 4 skizziert. 
Diese Ablaufsteuerung erzeugt eine Server-Anfrage zur Durchfiihrung einer 
Ferndiagnose. Sie konfiguriert die Funktionen im Fahrzeug, beispielsweise durch 
Festlegen einer Tester-Present-Nachricht^Einstellen der Timing-Parameter fiir das 
Transport-Protokoll und gegebenenfalls Einstellen der Parameter fiir die CAN- 
Kommunikation. Die Ablaufsteuerung fiihrt femer die Diagnose-Kommunikation durch 
zyklisches Generieirung von Tester-Present-Nachrichten mit den zu diagnostizierenden 
Steuereinheiten durch. Ferner werden von ihr die vom Server iibertragenen Diagnose- 
Kommandos auf das CAN-Transport-Protokoll umgesetzt. Dariiber hinaus ubertragt das 
Ablaufdiagramm die Daten an den Server und setzt zu diesem Zweck die im Fahrzeug 
ermittelten Diagnose-Daten auf die Mobilfunkschnittstelle urn. Dariiber hinaus sind 
MaBnahmen getroffen, mit denen in einem Ausfiihrungsbeispiel die bewerteten 
Ergebnisse der Fehleranalyse, die vom Server ubermittelt werden, angezeigt werden. 
Ferner ubernimmt die Ablaufsteuerung die Beendigung der Diagnose-Kommunikation 
durch Stoppen der Generierung von Tester-Present-Nachrichten. Dariiber hinaus wird in 
einem Ausfiihrungsbeispiel das automatische Beenden eines unterbrochenen 
Diagnosevorgangs, z.B. durch Timeout oder Watchdog fiir den Empfang von Server- 
Kommandos, durchgefuhrt. 

Das im Client 4 vorgesehene Transport-Protokoll-Modiil 4d fiihrt die tJbertragung von 
komplexen Nachrichten oder Dateneinheiten iiber einen CAN-Bus durch, nimmt die 
Entkopplung des Diagnose-Protokolls vom physikalischen ttbertragungsmedium vor und 
stellt die Dienste des OSI-Layers 3 (Network Layer) zur Verfugung,' sowie die 
Verbindung zwischen dem OSI-Layer 2 (Data Link Layer) und 7 (Applikation Layer). Es 
werden als also vom Transport-Protokoll-Modul eine Segmentierung und Erfassung von 
Daten des Data Link Layers vorgenommen, das heiBt die Steuerung des Datenflusses 
einzelner Botschaften inklusive Verwaltung und Zuordnung von physikalischen CAN- 
Botschaften zu logischen Nachrichten oder Dateneinheiten sowie die Fehlererkennung. 
Eine Realisierung stellt das allgemein verbreitete ISO-Transport-Protokoll (ISO 15765-2) 
dar, wobei in anderen Anwendungen auch spezielle Varianten dieses Protokolls 
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eingesetzt werden. Dies gilt auch bei der Verwendung anderer Bussysteme zur 
Kommunikation mit den Fahrzeugsteuergeraten. 

Das dem Server zugeordnete Diagnose-Protokoll-Modul 7d umfasst die Diagnoseschicht, 
welche in einer bevorzugten Anwendung das nach ISO spezifizierte Diagnose-Protokoll 
KWP2000 enthalt, wobei je nach Ausfiihrungsbeispiel auch Varianten davon eingesetzt 
werden. In diesem Diagnose-Protokoll-Modul sind spezielle Diagnose-Dienste definiert, 
die je nach Kraftfahrzeughersteller und/oder Kraftfahrzeugtyp unterschiedlich genutzt 
werden und zum Teil unterschiedliche Zusatzdienste enthalten. Das Diagnose-Protokoll- 
Modul wertet die Diagnose-Anfragen aus. Weitere Aufgaben, die durch das Modul gelost 
werden, sind die Konvertierung von Diensten in eine funktionale Schnittstelle fur die 
Anwendungsschicht, die direkte Nutzung spezieller Dienste und die 
Ausnahmebehandlung bei Nutzung von unbekannten Diensten. Ein Beispiel fur die 
Realisierung eines solchen Modul ist aus den nachfolgend beschriebenen 
Vorgehensweisen entnehmbar. 

Die grundsatzliche Vorgehensweise im Rahmen der Ferndiagnose besteht darin, dass 
nach Aktivierung der Ferndiagnose durch eine Bedienperson, z.B. den Nutzer des 
Kfaftfahrzeugs, und/oder den Service-Provider und/oder den Fahrzeughersteller und/oder 
eines Monteurs einer Werkstatt nach Abschluss der MaBnahmen zum Verbindungsaufbau 
zwischen Endger&t und Server die Kommandos des fahrzeugspezifischen Diagnose- 
Protokolls iiber die Luftschnittstelle vom Server zum Endgerat iibertragen werden. Die 
fahrzeugspezifischen Diagnose-Protokoll-Kommandos werden dabei vom Diagnose- 
Server nach Identifizierung des zu diagnostizierenden Kraftfahrzeugs aus einer 
Datenbank ausgelesen. Das Endgerat setzt die iibertragenen Diagnose-Kommandos auf 
das Fahrzeugnetzwerk urn. Die erfolgt beispielsweise dadurch, dass die empfangenen 
Kommandos in Kommandos fiir das diagnostizierende Steuergerat umgesetzt werden und 
iiber die Schnittstelle zum Fahrzeugnetzwerk, insbesondere iiber einen CAN-Bus, an das 
Steuergerat gesendet werden. Die Antwort dieses Steuergerats wird als Datennachricht 
aus dem Fahrzeugnetzwerk im entsprechenden Format iiber die 
Fahrzeugnetzwerkschnittstelle empfangen und wird dann vom Endgerat in 
Antwortnachrichten fur den Server umgesetzt. Diese werden dann an die 
Mobilfunkschnittstelle iibermittelt, die die Nachricht iiber ein vorgesehenes 
Obertragungs-Protokoll (beispielsweise im Rahmen des GSM-Standards) an den Server 
geschickt wird. Zusammenfassend setzt der Client im bevorzugten Ausfiihrungsbeispiel 
also das vom Server ubertragene Diagnose-Protokoll (KWP2000) auf das CAN- 
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Transport-Protokoll urn und umgekehrt. Die Ablaufsteuerung des beschriebenen 
Vorgangs zur Aufrechterhaltung der Diagnose-Kommunikation imFahrzeug erfolgt im 
Endgerat autark, beispielsweise durch sogenannte Tester-Present-Nachrichten. Diese sind 
in der KWP2000-Spezifikation definiert und dienen der Erfiillung der zeitlichen 
Anforderungen der Fahrzeugnetzwerkes. Dadurch wird eine Entkopplung der 
zeitkritischen Diagnose-Kommunikation imFahrzeug von den zeitunkritischen 
Diagnoseablaufen im Server erreicht. Ergebnis ist somit eine flexible Konfiguration der 
fahrzeugspezifischen Diagnose-Kommunikation imFahrzeug, die nicht durch mbgliche 
Probleme der Luftschnittstelle und der Diagnoseablaufe im Server belastet ist. 

Figur 3 zeigt ein Ablaufdiagramm des Gesamtvorgangs, der in funf grundlegende 
Teilschritte gegliedert ist. Die detaillierten Ablaufe innerhalb eines sdlchen Teilvorgangs 
sind je nach Fahrzeugtyp, dem moglicherweise vorliegenden Fehlerfall und/oder der 
jeweiligen Implementierung des Systems im Diagnose-Server variierbar. Im ersten Schritt 
. 100 erfolgt das Starten der Diagnose mit einer entsprechenden Anfrage an den Server. 
Die Aktivierung erfolgt dabei im bevorzugten Ausfiihrungsbeispiel durch den Fahrer 
bzw. Nutzer des Kraftfahrzeugs der durch Anruf oder Ahnliches beim Service-Center 
eine Aufforderung des Servers an den Client im Fahrzeug erzeugt, eine Diagnose- 
Verbindung aufzubauen. Der Client baut dann die angef orderte Verbindung auf. In 
anderen Ausfuhrungsbeispielen wird die Diagnose-Verbindung durch eine Anfrage vom 
Client aus aufgebaut. Der Aufbau der eigentlichen Diagnose-Verbindung erfolgt hier 
durch den Server oder den Client. Im nachsten Schritt 200 erfolgt die Konfiguration der 
Femdiagnose-Funktionalitat im Fahrzeug durch den Server. Dabei wird die 
Ablaufansteuerung, die Transportschicht und gegebenenfalls die CAN-Komrnunikation 
an das spezifische Fahrzeug angepasst. Dies erfolgt durch Kommandos bzw. Daten vom 
Server, die dieser aus einer Datenbank fur das spezielle Fahrzeug bzw. Fahrzeugtyp / 
und/oder Austattungsvariante ausliest. Bei der Aktivierung erhalt der Server 
beispielsweise mittels eines Identifikationscodes Informationen iiber das zu 
diagnostizierende Fahrzeug. Anhand dieser Information liest er fahrzeugspezifische 
Parameter, aus der Datenbank aus, die er dann an den Client zur Konfiguration der 
Femdiagnose-Funktionalitat ubennittelt. 

Nach den Teilschritten Aktivierung (100) und Initialisierung (200) wird der Teilschritt 
Ausfuhrung des Diagnosevorgangs (301 bis 303) an einem Beispiel eines Steuergerats 
gezeigt. Zunachst wird im Schritt 301 durch den Server im zu diagnostizierenden 
Steuergerat, sofem dies notwendig ist, der Diagnosemode angestoBen, so dass das 
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Steuergerat zum Ausfiihren der Diagnose-Funktion in der Lage ist Ferner erfolgt die 
Identifikation des Steuergerat, z.B. dessen Soflwarestand zur Anpassurig der Diagnose- 
Kommandos an den speziellen Steuergeratetyp. Auch dies ist optional und wird dann 
eingesetzt, wenn dies z.B. aufgrund der Vielzahl von Softstanden sich als erforderlich 
erweist Danach werden die ausgewahlten Diagnose-Kommandos vom Server an den 
Client imFahrzeug iibertragen. Beispiele fur solche Diagnose-Kommandos sind das 
Auslesen wenigstens eines Fehlerspeichers des betroffenen Steuergerats, das Auslesen 
von gespeicherten Umgebungs-Parameter eines aufgetretenen Fehlers und/oder das 
Abfragen von zusatzlichen Ist-Werten aus dem entsprechenden Steuergerat. 

Im Schritt 302 setzt der Client das oder die ubermittelten Diagnose-Kommandos auf das 
Fahrzeugnetzwerk urn. Im darauf folgenden Schritt 303 wird die Antwort des 
Steuergerats auf das oder die gesendeten Kommandos, welche beispielsweise innerhalb 
einer bestimmten Zeitperiode auftreten muss, empfangen, vom Client iiber auf die 
Ubertragungsschnittstelle zum Server umgesetzt und an diesen zuriickgesendet. Die 
Schritte 301 bis 303 werden dann fur jedes zu diagnostizierende Steuergerat oder, wenn 
die Diagnosekommandos einzeln nacheinander oder in Gruppen nacheinander versendet 
werden, fur jedes einzelne Diagnose-Kommando oder Diagnose-Kommando-Gruppe 
wiederholt. Ist die Diagnose fur ein Steuergerat beendet, wird als Diagnose-Kommando 
ein Ende-Kommando gesendet, welches ggf. den Diagnose-Mode im Steuergerat 
deaktiviert und dieses wieder in den normalen Betriebsmode zuriickversetzt. 

Der vierte Teilschritt betrifft die Auswertung der erhaltenen Daten im Server (Schritt 
400). Der Server wertet der nach MaBgabe eines ggf. spezifischen Algorithmus die 
gesammelten Fehlerinformationen aus, ermittelt ein Diagnose-Ergebnis und/oder 
Empfehlungen fur das weitere Vorgehen. Im darauf folgenden Schritt 500 werden dann 
die vom Server ermittelten Ergebnisse an das Endgerat iibertragen und von diesem im 
Fahrzeug angezeigt. Dieser fiinfte Teilschritt stelle somit die Ergebnisausgabe dar. Im 
diesem Schritt ist auch in einem Ausfuhrungsbeispiel die tjbermittlung und Anzeige einer 
Empfehlung fiir das weitere Vorgehen imFehlerfall vorgesehen, z.B. „Werkstatt 
aufsuchen", etc. 

Figur 4 zeigt ein beispielhaftes Kommunikationsszenario zwischen einem Ferndiagnose- 
Server, einem Telematikendgerat und einem Steuergerat. Das Kommunikationsszenario 
stallt eine Realisierung des dritten Teilschritt in Figur 3 im Detail dar. Basis der 
Kommunikation ist das nach ISO 14230-3 spezifizierte Diagnose-Protokoll KWP2000. In 



anderen Ausfuhrungsbeispielen werden herstellerspezifische Varianten dieses Diagnose- 
Protokolls Oder auch andere Diagnose-Protokolle entsprechend eingesetzt. Je nach 
Ausfuhrungsbeispiel variiert die Abfolge der Scbritte und der Umfang der Scbxitte in den 
einzelnen Anwendungen. Figur 4 zeigt eine bevorzugte Realisierung der Kommunikation 
zwischen einemFemdiagnose-Server I, einem imFahrzeug angeordneten 
Telematikendgerat H und einem zu diagnostizierenden Steuergerat EL Die 
Kommunikation basiert dabei auf dem Diagnose-Protokoll KWP2000, welches in der 
ISO 14230-3 spezifiziert ist. Die Fehlerermittlung und das Setzen der Fehlerspeicher 
erfolgt dabei in den meisten Falle durch bekannte Diagnosemethoden im zu 
diagnostizierenden Steuergerat durch dort vorhandene oder dort eingelesene Software. 

In Figur 4 sind die einzelnen einer Kommunikation zwischen den drei beteiligten 
Einheiten dargestellt, wobei von oben nach unten eine zeitliche Reihenfolge ausgedriickt 
sein soil. In den Einheiten sind Softwareprogramme vorhanden, die die zu ubermittlenden 
Nachrichten erzeugen, auswerten, etc. 
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Nach Abschluss der Teilvorgange 1 und 2 (siehe Figur 3, Schritte 100 und 200) wird in 
einem ersten Schritt SI der Diagnose-Mode im zu diagnostizierenden Steuergerat 
aktiviert. Dazu sendet der Server ein entsprechendes Diagnose-Kommando (Start- 
Diagnostic-Session-Request). Dieses wird vomEndgerat empfangen und uber die 
SchnittsteUe zum diagnostizierenden Steuergerat weitergeleitet (Schritt S2) bzw. zuerst in 
ein fur das Fahrzeugnetz geeignetes Format umgesetzt (z.B . mittels einer Tabelle) und 
dann auf das Fahrzeugnetz gegeben. Das zu diagnostizierende Steuergerat antwortet mit 
einer entsprechenden Antwort (Start-Diagnostic-Session-Response), die angibt, ob der 
Diagnose-Mode eingeleitet ist oder nicht. Diese Information sendet das zu 
diagnostizierende Steuergerat im Schritt S3 zum Endgerat, welches wiederum im Schritt 
S4 (ggf. nach Umsetzung auf das vorgesehene Format) die Information zum Server 
iibertragt. 

Daraufhin wird zur Ablaufsteuerung und zur Erfullung der Zeitanforderung im 
Fahrzeugnetz vomEndgerat E zum Steuergerat IE im Schritt S5 eine Kommando 
geschickt (Tester-Present=Request),Twelches im Schritt S6 von Steuergerat mit einer 
entsprechenden Antwort (Tester-Present-Response) beantwortet wird. Diese 
Kommunikation wird im folgenden wahrend des Diagnosevorgangs dann ausgefuhrt, 
wenn vom Server kein anderes Diagnose-Kommando weiterzuleiten ist bzw. vom 
Steuergerat keine Antwort an den Server zu leiten ist. Daher konnen die Schritte S5 und 
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S6 auch mehrfach wiederholt werden, solange bis das erwartete Kommando vom Server 
empf angen wird. Tritt eines der genannten Ereignisse nicht auf, wird die Kommunikation 
zwischen Endgerat und Steuergerat abgebrochen. 

Nach Empfang der Antwort im Schritt S4 sendet der Server im Schritt S7 ein Kommando 
(Read ECU-Identification-Request), welches die Identification des zu diagnostierenden 
Steuergerats anfragt Dieses Kommando wird vom Endgerat empfangen und ggf. 
umgesetzt und dann im Schritt S8 zum Steuergerat iibermittelt. Das Steuergerat liest aus 
seinem Speicher daraufhin wenigstens einen Identifikationsparameter aus und sendet 
diesen zum Endgerat (Read ECU-Identification-Response, Schritt S9). Diese Information 
wird dann ggf. nach Umsetzung vom Endgerat II im Schritt S10 an den Server 
ubertragen. Anhand des Identifikationsparameters erkennt der Server das Steuergerat, 
gegebenenfalls dessen Software-Stand sowie gegebenenfalls das Fahrzeug und wahlt aus 
der Datenbank entsprechende Parameter aus. In der Zwischenzeit lauft, wie anhand der 
Schritte S 1 1 und S 12 dargestellt, zwischen Endgerat und zu diagnostizierenden 
Steuergerat die oben beschriebene Tester-Present-Kommunikation ab, die sicherstellt, 
dass die Kommunikation zwischen Endgerat und Sfeuergerat aufrechterhalten bleibt, das 
Steuergerat im Diagnosemode verbleibt und keine Verletzung der Randbedingungen fur 
die Kommunikation im Fahrzeugsnetz, die zum Abbruch fuhrt, erf olgt. 

In den nachsten Schritten werden die Fehlerspeicher des zu diagnostizierenden 
Steuergerats ausgelesen. Dazu iibermittelt der Server nach Empfang der Nachricht im 
Schritt S10 und Auslesen der steuergeratspezifischen Parameter zum Endgerat im Schritt 
S13 eine entsprechende Anfrage (Read DTC-Request). In dieser Anfrage sind die 
steuergeratspezifischen Parameter enthalten, in denen z.B. angegeben ist, welche 
Fehlerspeicher auszulesen sind. Diese Anfrage wird im Schritt S14 von Endgerat ggf. 
nach Umsetzung zum Steuergerat ubertragen. Das Steuergerat fuhrt die empfangenen 
Kommandos aus und sendet die Fehlerspeicherinhalte als Botschaft Read DTC-Response 
im Schritt S15 zum Endgerat. Die Botschaft Read DTC-Response enthalt demnach die 
relevanten Fehlerspeicherinhalte. Die Antwort wird vom Endgerat ggf. nach Umsetzung 
im Schritt ST6 zum Server ubertragen. Daraufhin wird in den Schritten S17 und S18 die 
oben erwahnte Tester-Present-Kommunikation zwischen Endgeratmnd-Steuergerat-bis 
zum erneuten Empfang einer Botschaft vom Server durchgefuhrt. 

Im darauf folgenden, optionalen Teilschritt werden die zu den Fehlereintragen gehorige 
Umgebungsparameter ausgelesen. Zu diesem Zweck sendet der Server nach Empfang der 
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Botschaft im Schritt S16 und nach Auswertung der Fehlereintrage im Schritt S19 an das 
Endgerat eine entsprechende Anfrage (Read-Freeze Frame-Request), die dieses ggf. nach 
Umsetzung im Schritt S20 an das Steuergerat weitergibL Je nach AusfQhrung Uest das 
SteuergerSt dann die gewiinschten Parameter zu den gespeicherten Fehlern aus oder der 
Server spezifiziert anhand der Inhalte der Fehlerspeicher den Inhalt seiner Botschaft, so 
dass mit dieser Botschaft nur bestimmte Umgebungsparameter angefordert werden. Das 
Steuergerat jedenfalls antwortet mit einer entsprechenden Antwort (Read-Freeze Frame- 
. Response), in welchem die auf die eine oder andere Weise angeforderten Parameter 
enthalten sind. Im Schritt S21 wird die Antwort an das Endgerat gesendet, welches die 
Antwort wiederum ggf- nach Umsetzung im Schritt S22 zum Server ubertrag. In den 
Schtitten S23 und S24 erfolgt emeut die Tester-Present-Kommunikation. 

Im darauf f olgenden Teilschritt, nach dem Fehlerspeicher und zugehorige 
Umgebungsparameter ausgelesen und iibertragen sind, wird der Diagnosemode im 
Steuergerat deaktiviert. Hierzu schickt der Server eine Aufforderung zum Beenden die 
Diagnosevorgangs (Stop-Diagnostic-Session-Request) an das Endgerat. Dieses gibt die 
Aufforderung zum Beenden an das Steuergerat weiter (Schritt S26), welches mit einem 
entsprechenden Antwortsignal (Stop-Diagnostic-Session-Response) im Schritt 27, mit 
welcher das Steuergerat die Beendigung des Diagnose-Modus mitteilt, antwortet Diese 
Information wird vom Endgerat im Schritt S28 zum Server iibertragen. Daraufhin (Schritt 
S29) werden die oben dargestellten Teilvorgange 4 und 5 beziiglich Auswertung und 
Anzeige derDiagnose-Ergebnisse und ggf. -Empfehlungen weitergefuhrt. 

Das dargestellte Kommunikationsszenario ist ein Beispiel. In anderen Ausfuhrungen 
fehlen die Schritte zum Aktivieren und Deaktivieren des Diagnose-Modes im Steuergerat 
und/oder zur Identifikation des Steuergerats und/oder zum Auslesen der zugehOrigen 
Umgebungsparameter. 

Die konkrete technische Realisierung der dargestellten Kommunikation findet durch 
entsprechende Software-Programme in Server, Endgerat und Steuergerat statt, die jedes 
fur sich ebenf alls Teil der vorliegenden Erfmdung sind. 
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Patentanspriiche 

1 . Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server) und einem Endgerat, welches vorzugsweise im Kraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekexinzeichnet, 
dass der Telematikdienst in Teilfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind, wobei im Server zeitunkritische 
Funktionalitaten, im Endgerat zeitkritische Funktionalitaten ablaufen.. 

2. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in Teilfunktionalitaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

3. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise im 
Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 

4. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
die zeitkritischen Teilfunktionalitaten autarkim Endgerat ablaufen, die 
zeitunkritischen Teilfunktionalitaten vom Server mittels Kommunikatioon mit dem 
Endgerat durchgefuhrt werden. 
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5. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
im Endgerat die zeitkritische Kommunikation mit einem zu diagnostizierenden 
Steuergerat und/oder einer zu diagnostizierenden Komponenten implementiert ist. 

6. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
der Telematikdienst eine Ferndiagnose eines Kraftfahrzeugs ist und dass das 
Diagnose-Protokoll im Server implementiert ist 

7. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
Kommandos des fahrzeugspezifischen Diagnose-Protokolls iiber eine 
Luftschnittstelle vom Server zum Endgerat iibertragen wird. 

8. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
das Endgerat die iibertragenen Diagnose-Kommandos auf ein Fahrzeugnetzwerk 
umsetzt und die erzeugten Antwortnachrichten an die Mobilfunkschnittstelle 
ubermittelt. 

9. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, dass 
als Diagnose-Protokoll KWP2000 oder eine Variante davon eingesetzt wird. 

10. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server) und einem Endgerat, welches vorzugsweise imKraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekennzeichnet, 
dass der Telematikdienst in Teilfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind. 

11. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in Teilfunktionalitaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

12. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise 
im Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 
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13. Vorrichtung nach Anspruch 10 oder 11, wobei der Server uber eine Luftschnittstelle 
mit dem Endgerat kommuniziert, dadurch gekennzeichnet, dass der Telematikdienst 
eine Ferndiagnose eines Kraftfahrzeugs ist, wobei das Diagnose-Protokoll als 
zeitunkritische Teilfunktionalitat im Server implementiert ist 

14. Vorrichtung nach Anspruch 10 oder 12, wobei das Endgerat uber eine 
Luftschnittstelle mit dem Server kommuniziert und welches eine weitere Schnittstelle 
umfasst, mit dem es mit einer zu diagnostizierenden Einheit verbunden ist, dadurch 
gekennzeichnet, dass das Endgerat als zeitkritische Teilfunktionalitat eine 
Ablaufsteuerung umfasst, die autark gegeniiber der zentralen Recheneinheit ist und 
die die Diagnose-Kommunikation im Fahrzeug aufrecht erhalt 

15. Computerprogramm mit Programmcode-Mitteln, urn alle Schritte von jedem 
beliebigen der Anspruche 1 bis 9 durchzufiihren, wenn das Programm auf einem 
Computer ausgefiihrt wird. 

16. Computerprogrammprodukt mit Programmcodemitteln, die auf einem 
computerlesbaren Datentrager gespeichert sind, urn das Verfahren nach jedem 
beliebigen der Anspruche 1 bis 9 durchzufiihren, wenn das Programmprodukt auf 
einem Computer ausgefiihrt wird. 
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Verfahren und Vorrichtung fiir einen fahrzeuebezogenen Telematikdienst 
Zusammenfassung 

Es werden ein Verfahren und Vorrichtung fur einen fahrzeugbezogenen Telematikdienst 
vorgeschlagen, bei welchem der Telematikdienst in Teilfunktionalitaten untergliedert ist 
und diese Teilfunktionalitaten auf Server und Endgerat aufgeteilt sind. 

(Figur2) 
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